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REMARKS 

Independent claims 1, 13, 21, 24 and 33 and 34 have been amended to clarify the 
invention over the art. Dependent claims 4, 7, 14 and 26 have been amended to conform with 
changes made in claims 1,13 and 24, respectively. Claims 4, 9, 13, 17, and 23 also have been 
amended to correct minor spelling and typographical errors. 

Turning to the rejection of claims 1-8, 13-16, 21-28, 33 and 34 under 35 USC §103 as 
obvious over a combination of Kannan et al. (U.S. Patent 5,81 5,702) and Anschuetz et al. (U.S. 
Patent 5,305,455), independent claims 1, 13, 21, 24, 33 and 34 have been amended to clarify that 
an exception is "caused due to a runtime fault in a thread executing an application." No 
combination of Kannan et al. and Anschuetz et al. teaches this feature. Anschuetz et al. deals 
only with handling an operating system (OS) level exception. Anschuetz et al. receives an 
exception of an OS, and dispatches the exception in the OS to an exception handler. The 
example exception occurs in a portion of processor 12 (col. 4, lines 24-35). The processor 12 
dispatches the exception to the OS 14 so that control is transferred to a kernel exception 
dispatcher 68 of the OS. This is an OS level exception, Anschuetz et al. does not disclose any 
"method for recovering an application from a runtime fault." (emphasis added) Thus, Anschuetz 
et al. does not teach "receiving an exception caused due to a runtime fault in a thread executing 
an application" (emphasis added), as required by Applicants' amended claims 1, 13, 21, 24, 33 
and 34. Furthermore, Kannan et al. does not supply the missing teaching to Anschuetz et al. to 
achieve or render obvious claims 1, 13, 21, 24, 33 and 34. Kannan et al. teaches a software 
product that enables a user to continue using an application that has generated a fatal exception. 
Kannan et al. does this by providing a crash guard process 107, an exception handler 115 and a 
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safe message loop 109 in the computer memory 103 (FIG. 1). The safe message loop 109 is "a 
portion of code that replaces, or substitutes for this main event or message loop of any 
application 105 once the application generates a fatal exception" (col. 4, lines 55-61). When the 
current instruction 302 of the application 105 generates 301 a fatal exception, the operating 
system 1 1 1 halts the execution of the application's instructions and sends fault data to the 
exception handler 115 (FIG. 3). If the user chooses to continue 311, the exception handler 1 1 5 
replaces 315, the address of the instruction register 121, with the location of the entry address of 
the safe message loop 109. The OS 1 1 1 uses this new address value and resumes its execution at 
the safe message loop 109. The thread of control 316 is within the safe message loop 109 (col. 7, 
lines 49-62). 

Kannan et al. suggests replacement of the existing offending message loop with the safe 
message loop 109. The safe message loop 109 is loaded into the memory 103 in advance (col. 6, 
lines 36-37). Thus, replacing the existing message loop with the safe message loop 109 may not 
always work where the user wants the application to continue to run as if nothing happened; and 
there may be some logic around the existing message loop that, if replaced with the safe message 
loop 109, may lead to undesired application behavior. Therefore, Kannan et al. does not disclose 
or suggest translation of the exception into an exception that the application is capable of 
handling, as recited in Applicants' amended claims 1, 13, 21, 24, 33 and 34. 

Accordingly, even if one skilled in the art terminated a thread when an OS level 
exception is received as per Anschuetz et al., and replaced an existing message loop of an 
application with a pre-stored safe message loop as per Kannan et al., he would still fail to 
provide a method that translates the exception into an exception that can be handled by the 
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application. Therefore, Applicants respectfully submit that the invention as claimed in claims 1, 
13, 21, 24, 33 and 34, and all claims dependent therefrom, are patentable over the combination of 
Anschuetz et al. and Kannan et al. 

Turning to the rejection of claims 9-12, 17-20 and 29-32 under 35 USC §103 as obvious 
over a combination of Kannan et al. and Anschuetz et al. in view of Le Vine et al. (U.S. Patent 
6,591,379), claims 9-12, 17-20 and 29-32 are all directly or indirectly dependent on claims 1, 13 
and 24. The deficiencies of the combination of Kannan et al. and Anschuetz et al. have been 
discussed above vis-a-vis claims 1,13 and 24. LeVine et al. does not supply the missing 
teaching to achieve or render obvious claims 1,13 and 24, or claims 9-12, 17-20 and 29-32, 
which depend thereon. LeVine et al. teaches injecting an exception into a hung program, rather 
than receiving an exception and dealing with it in a way to preserve the state of the running 
application. Accordingly, it is respectfully submitted that if one skilled in the art combined the 
teaching of LeVine et al. with Kannan et al. and Anschuetz et al., such combination would fail to 
translate a received exception occurred in an application into an exception that can be handled by 
the application, as recited in claims 1,13 and 24. Therefore, no combination of Kannan et al., 
Anshuetz et al. and LeVine et al. could achieve or render obvious claims 9-12, 17-20 and 29-32. 

Having dealt with all the objections raised by the Examiner, the Application is believed 
to be in order for allowance. Early and favorable action are respectfully requested. 
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In the event there are any fee deficiencies or additional fees are payable, please charge 
them (or credit any overpayment) to our Deposit Account Number 08-1391. 

Respectfully submitted, 

WED 




Norman P. Soloway ^ APR 2 8 2004 

Attorney for Applicants _ , , . , „. nn 
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